【网络】RST详解

😀现实很近又很冷，梦想很远却很温暖 ​

欢迎关注

以下内容来源：https://mp.weixin.qq.com/s/Fr6o6gRiIUIspV9-jR9snw 作者：小白debug 注：内容有所改动

我们都知道TCP正常情况下断开连接是用四次挥手，那是正常时候的优雅做法。 但异常情况下，收发双方都不一定正常，连挥手这件事本身都可能做不到，所以就需要一个机制去强行关闭连接。 RST 就是用于这种情况，一般用来异常地关闭一个连接。它是一个TCP包头中的标志位。 正常情况下，不管是发出，还是收到置了这个标志位的数据包，相应的内存、端口等连接资源都会被释放。从效果上来看就是TCP连接被关闭了。 而接收到 RST的一方，一般会看到一个 connection reset 或 connection refused 的报错。

我们知道内核跟应用层是分开的两层，网络通信功能在内核，我们的客户端或服务端属于应用层。应用层只能通过 send/recv 与内核交互，才能感知到内核是不是收到了RST。 ​

当本端收到远端发来的RST后，内核已经认为此链接已经关闭。此时如果本端应用层尝试去执行 读数据操作，比如recv，应用层就会收到 Connection reset by peer 的报错，意思是远端已经关闭连接。 如果本端应用层尝试去执行写数据操作，比如send，那么应用层就会收到 Broken pipe 的报错，意思是发送通道已经坏了。 这两个是开发过程中很经常遇到的报错，感觉大家可以把这篇文章放进收藏夹吃灰了，等遇到这个问题了，再打开来擦擦灰，说不定对你会有帮助。

RST一般出现于异常情况，归类为 对端的端口不可用 和 socket提前关闭。

端口不可用分为两种情况。要么是这个端口从来就没有"可用"过，比如根本就没监听**（listen）过；要么就是曾经"可用"，但现在"不可用"了，比如服务突然崩**了。

服务端listen 方法会创建一个sock放入到全局的哈希表中。 此时客户端发起一个connect请求到服务端。服务端在收到数据包之后，第一时间会根据IP和端口从哈希表里去获取sock。

如果服务端执行过listen，就能从全局哈希表里拿到sock。 ​

但如果服务端没有执行过listen，那哈希表里也就不会有对应的sock，结果当然是拿不到。此时，正常情况下服务端会发RST给客户端。 ​

不一定。上面提到，发RST的前提是正常情况下，我们看下源码。

收到RST包，第一步会通过tcp_sequence先看下这个seq是否合法，其实主要是看下这个seq是否在合法接收窗口范围内。如果不在范围内，这个RST包就会被丢弃。 至于接收窗口是个啥，我们先看下面这个图。 这里黄色的部分，就是指接收窗口，只要RST包的seq不在这个窗口范围内，那就会被丢弃。

正常情况下客户端服务端双方可以通过RST来断开连接。假设不做seq校验，如果这时候有不怀好意的第三方介入，构造了一个RST包，且在TCP和IP等报头都填上客户端的信息，发到服务端，那么服务端就会断开这个连接。同理也可以伪造服务端的包发给客户端。这就叫RST攻击 ​

受到RST攻击时，从现象上看，客户端老感觉服务端崩了，这非常影响用户体验。 如果这是个游戏，我相信多崩几次，第二天大家就不来玩了。 ​

实际消息发送过程中，接收窗口是不断移动的，seq也是在飞快的变动中，此时第三方是比较难构造出合法seq的RST包的，那么通过这个seq校验，就可以拦下了很多不合法的消息。 ​

**不是，只是增加了攻击的成本。**但如果想搞，还是可搞的。 ​

以下是面向监狱编程的环节。 希望大家只了解原理就好了，不建议使用。相信大家都不喜欢穿着蓝白条纹的衣服，拍纯狱风的照片。 ​

从上面可以知道，不是每一个RST包都会导致连接重置的，要求是这个RST包的seq要在窗口范围内，所以，问题就变成了，我们怎么样才能构造出合法的seq。

窗口数值seq本质上只是个uint32类型。

如果在这个范围内疯狂猜测seq数值，并构造对应的包，发到目的机器，虽然概率低，但是总是能被试出来，从而实现RST攻击。这种乱棍打死老师傅的方式，就是所谓的合法窗口盲打（blind in-window attacks）。 觉得这种方式比较笨？那有没有聪明点的方式，还真有，但是在这之前需要先看下面的这个问题。 ​

我们需要了解一个问题，比如服务端在已连接（ESTABLISHED）状态下，如果收到客户端发来的第一次握手包（SYN），会怎么样？ ​

以前我以为服务单会认为客户端憨憨了，直接RST连接。 但实际，并不是。

当客户端发出一个不在合法窗口内的SYN包的时候，服务端会发一个带有正确的seq数据ACK包出来，这个ACK包叫 challenge ack。 上图是抓包的结果，用scapy随便伪造一个seq=5的包发到服务端（端口9090），服务端回复一个带有正确seq值的challenge ack包给客户端（端口8888）。

上面提到的这个challenge ack ，仿佛为盲猜seq的老哥们打开了一个新世界。 在获得这个challenge ack后，攻击程序就可以以ack值为基础，在一定范围内设置seq，这样造成RST攻击的几率就大大增加了。